home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000035_owner-urn-ietf _Thu Oct 10 01:31:01 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA08413 for urn-ietf-out; Thu, 10 Oct 1996 01:31:01 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA08408 for <urn-ietf@services.bunyip.com>; Thu, 10 Oct 1996 01:30:58 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02752  (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 01:30:56 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16998(4)>; Wed, 9 Oct 1996 22:30:51 PDT
  6. Received: by golden.parc.xerox.com id <2764>; Wed, 9 Oct 1996 22:30:36 PDT
  7. To: gjw@wnetc.com
  8. Cc: michaelm@rwhois.net, michaelm@internic.net, rdaniel@acl.lanl.gov,
  9.         urn-ietf@bunyip.com
  10. In-Reply-To: <Pine.SGI.3.95.961009205216.11077C-100000@shellx.best.com>
  11.     (gjw@wnetc.com)
  12. Subject: Re: [URN] advantages of NAPTR over PURLs
  13. From: Larry Masinter <masinter@parc.xerox.com>
  14. Message-Id: <96Oct9.223036pdt."2764"@golden.parc.xerox.com>
  15. Date: Wed, 9 Oct 1996 22:30:36 PDT
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. > Actually, the fact that the NAPTR proposal uses DNS as part of its
  22. > infrastructure doesn't seem to me to be a huge issue.
  23.  
  24. Oh, I think it's the source of most of its problems. If it were in
  25. some application protocol rather than DNS -- something that had a
  26. reasonable administrative & security model and a distributed
  27. implementation that actually dealt with updates -- most of the
  28. problems I have with it would go away.
  29.  
  30. > One point though: adminisration and security are two things you do AFTER
  31. > you have a system that can scale and function. If you don't have 
  32. > something that works then all the security and administration in the
  33. > world won't get you squat.
  34.  
  35. This just doesn't hold water. Most of the issues we have to deal with
  36. in 'scalability' are administration and security. We can't design
  37. protocols that way any more. It is completely unacceptable that after
  38. three years of talking about URNs and meeting about URNs that the
  39. first 'URN implementation' doesn't have a credible story about
  40. administration and security.
  41.  
  42. Larry